Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-162.txt

Text File | 1994-12-08 | 54.5 KB | 998 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sat, 08 Aug 92       Volume 1 : Issue 162

Today's Topics:

    Location of selected printer?
    Religious Question: How Do The Metaphors Fit Together?
    Is System 7 written in C++?



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] ( Philippe Cinquin)
Subject: Location of selected printer?
Date: 3 Jul 92 17:30:42 GMT
Organization: IMAG Institute, University of Grenoble, France

Just a simple question (I hope!): where is the name of the printer choosen
by the user through the chooser stored? How can I get it and change it?
(I know I normally shouldn't change it, but this is a special case).

If you email please do so at " [e-mail] ". Thanks in advance.

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 4 Jul 92 16:07:47 GMT
Organization: The World Public Access UNIX, Brookline, MA

The name of the printer is stored in the printer driver. The name of the
printer driver is stored in the system file. There are some gotchas if you
try to change these, so don't! That's what the Chooser is for.


- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP
- -- asm.comm.networks.cool tunes...

---------------------------

From: [e-mail] (P. Hawthorne)
Subject: Religious Question: How Do The Metaphors Fit Together?
Date: 6 Jul 92 01:03:41 GMT
Organization: Reed College, Portland OR

I am afraid I am a casualty of object orientation. In trying to put the
parts of the standard user interface together in a consistent framework,
I have become confused about how they ought to fit together.  I feel like
Winnie the Pooh looking for the North Pole, blind to the metal rod right
under his very nose... :-)

The notion of a selection dominates the edit commands, even more so than
the clipboard. If there is no current selection, the cut, copy and clear
commands are dim. If there is no chance of having a selection in a given
situation or the selection does not accept the contents of the clipboard,
the paste command is dim. So, it appears that the clipboard is a servant of
the selection. Fine, great, so...

The selection itself appears to be an aspect of the window. The window
draws and erases the selection when it is activated or deactivated.
However, when one has more than one window open showing part of the same
document, the windows are actually sharing the same selection. So the
selection can be an aspect of the window that is actually a reference to
an aspect of the document.

As if that were way too easy, some windows use one of many forms of
selection which might not have anything to do with the document per se.
Windows such as dialogs that edit a part of the document often have their
own notion of selection such as: the blinking insertion caret in an edit
text dialog item; or a window in which one can have selected either
icons, part of the name of an icon, or arcs between icons.

So at any time there is one current application, one current window that
implies one current document, and one current selection. Does this sound
right or am I missing something? Does anyone else wonder about all this?
Could it be that I have become completely obsessed?

 Theus ([e-mail])
(If you consider this a waste of bandwidth, I beg your pardon.)

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 6 Jul 92 06:38:40 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (P. Hawthorne)
writes:

[sorry for rearranging the bits of your posting, but it seemed easier
to respond to them in this order...]

> So at any time there is one current application, one current window that
> implies one current document, and one current selection.

Yup, this is how it's supposed to be. It's certainly what the AppleEvent
Object Model expects.

> As if that were way too easy, some windows use one of many forms of
> selection which might not have anything to do with the document per se.
> Windows such as dialogs that edit a part of the document often have their
> own notion of selection such as: the blinking insertion caret in an edit
> text dialog item; or a window in which one can have selected either
> icons, part of the name of an icon, or arcs between icons.

Well, the selection has to do with whatever is being manipulated in the
window. The window might be a dialog for examining and changing settings
to do with a document. Consider the standard PutFile dialog in System 7;
the current selection can either be an item in a list, or some part of
an editable text field. The only reason you can't select both sorts of
things at once is simply because it doesn't make sense, given the way
the dialog is supposed to work.

> The selection itself appears to be an aspect of the window. The window
> draws and erases the selection when it is activated or deactivated.
> However, when one has more than one window open showing part of the same
> document, the windows are actually sharing the same selection. So the
> selection can be an aspect of the window that is actually a reference to
> an aspect of the document.

In my experience, the handling of multiple views of the same document
tends to vary somewhat. In spite of all the bad things that M#%$#S@ft have
done, Excel *can* serve as a useful model in this one respect: it lets
you split a window into panes, so that you can do useful things like
manipulate all four corners of a large rectangular selection without lots
of scrolling.

The MPW Shell (3.2 and later) has a similar, if more elaborate, scheme.
It only shows you the selection in one window pane at a time, but otherwise
the selection behaves similarly to Excel--you can click at one point in
one pane, and then shift-click at a different point being shown in another
pane, to select everything between those two points in the document.

For those applications that let you open multiple separate windows
showing the same document, the selection in each window is usually independent.
Thus, it might be considered to be a property of the window, not of the
document. But then the question arises of which selection you save with the
document.

I just checked this in Claris Resolve, and it's got a solution I wasn't
aware of before. I opened a new worksheet, selected cell C17, typed something
into it, and then saved and closed the worksheet. Then I reopened it, asked
for a "New View" (which creates a new window showing the same document),
selected cell C6 in the new window, and typed something else in, leaving
C6 selected. Next I went back to the first window, where cell C17 was still
selected, and saved my changes with that window in front. And guess what--it
saved the fact that I had two views open! When I reopened the document, I got
two windows, the first with cell C17 selected, the second with cell C6 selected.

So there's an interesting solution for you. I still wish Resolve had
Excel-style panes (and no, "Titles" are *not* a satisfactory substitute), but
it's obvious the user-interface folks at Claris haven't been *completely*
asleep. :-)

> Could it be that I have become completely obsessed?

All the good Mac hackers are. :-)

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Ask not for whom the phone rings; it rings for you.

---------------------------

From: [e-mail] (Ian Joyner)
Subject: Is System 7 written in C++?
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Thu, 28 May 1992 01:34:08 GMT

Kent,

Here is a question for you or anyone else who cares to clarify this point.
You may have read in comp.lang.c++ that Andrew Koenig claimed that
system 7 was rewritten in C++, from object Pascal. To my knowledge
previous systems were written in 68000 assembler, not OP. I believe
Finder has been rewritten in C++ (can't remember where I got this from,
maybe this newsgroup), but has the whole of system 7 been written
in C++?

Thanks for the clarification :-)

- --
Ian Joyner                                     ACSNet: [e-mail]
ACUS (Australian Centre for Unisys Software)   Internet: [e-mail]
115-117 Wicks Rd, North Ryde, N.S.W, Australia 2113.
Tel [phone]      Fax [phone]       UUCP: ...uunet!munnari!syacus.oz

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 28 May 92 18:05:30 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Ian Joyner) writes:
> Kent,
>
> Here is a question for you or anyone else who cares to clarify this point.
> You may have read in comp.lang.c++ that Andrew Koenig claimed that
> system 7 was rewritten in C++, from object Pascal. To my knowledge
> previous systems were written in 68000 assembler, not OP. I believe
> Finder has been rewritten in C++ (can't remember where I got this from,
> maybe this newsgroup), but has the whole of system 7 been written
> in C++?

I think it's difficult to say that any particular language was used
to write the Mac system.  Parts are writtren in a variety of languages.
680X0 asm is a good chunk, Pascal and C code are in there in some
places.  C++ was used to write most of the new Finder.

What does it really matter?

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --  Makers of...        --   San Jose, California USA 95117
- --                      --   voice: [phone] fax: [phone]
- --     SMOOTHIE         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (David Casseres)
Date: 28 May 92 16:50:39 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Ian Joyner) writes:

> Here is a question for you or anyone else who cares to clarify this point.
> You may have read in comp.lang.c++ that Andrew Koenig claimed that
> system 7 was rewritten in C++, from object Pascal. To my knowledge
> previous systems were written in 68000 assembler, not OP. I believe
> Finder has been rewritten in C++ (can't remember where I got this from,
> maybe this newsgroup), but has the whole of system 7 been written
> in C++?

Parts of System 7, notably the Finder, were rewritten in C++.  Parts are in C,
and some parts may still be Pascal.  I don't believe any of it was ever Object
Pascal, but previous systems were written in a mixture of assembly and Pascal.

(I guess if you want to be very technical about it, Mac Pascal *is* s arguments, I'm inclined to
. agree with him. I forget what issue it was, but I know that he wrote or is
. writing some sort of BASIC compiler for HyperCard or something.

  Somehow it seems that a BASIC compiler for HyperCard sounds like frozen
molasses moving uphill during a Utah Winter. First impressions, I guess...

  Unless there is a lot of time or experience devoted to making the lowest
levels of a framework as tight as possible, any layered project is going to
be slow. Sometimes it seems that you can have only ever have a robust
project, an efficient project, or a lackluster tradeoff between the two.

  Imho, anything extending HyperCard functionality is going to have to be
just blatantly and convincingly fast or it could be dismissed as a dog.
Interesting point, though. Understable for this guy to make it, given the
project you say he's working on.


  Matt Mora, [e-mail], quite rightly mentions:
. Speed of the application is dependent upon the "smartness" of the
. compiler and the skill of the programmer not the language used.  You
. can't make general claims like that about languages.

  Granted. However, there must be some plausible explanation for why so
many C programmers so often claim that C is inherently faster than Pascal,
or why so many C programmers cite the bad points of ancient Pascal dialects
as proof of the superiority of C.

  One of the things I hear most often is that C is more "low level" than
Pascal, and therefore obviously going to be faster. Dubious, ain't it?

  Imho, the idea that a lower level of abstraction brings with it speed
flies in the face of algorithms and problem solving.

  For instance, I find that the "with" statement in Pascal helps me to
write and read much more expressive code for the perfect data structure in
the appropriate algorithm than, say, register variables in C helps me to.

  While I yearn for a macro facility and an assembler within Pascal, I owe
a great deal of the efficiency of the projects I can write in a finite
amount of time to the "with" statement. I'm not trying to start a flamewar
here, just pointing out something I find significant.


  Matt Mora then goes on to say:
. Think Pascal has been proven to beat Think C in a few examples in producing
. faster code. This was in the past before Think C had an optimizer. Things
. have probably changed since then.

  The two do seem to be equivalent in speed of compiled code. Of course,
the best compiler optimization pales against a more appropriate algorithm.
Then again, Pascal does seem to be going the way of Pick and News... A lot
more people write C compilers than Pascal compilers in school... I dare say
that real soon now, comparing C and Pascal will be like comparing fractals
and Newtonian forward differencing. (What's that? That's the point.)

  I dunno for sure, but I think that both of those products could be
optimized further. I have written anything that does a better job, so my
opinion isn't really worth anything at all. I suspect, however, register
allocation could be improved with peephole optimization tempered by special
cases for the register-based traps.

  My kingdom for a new and improved object method dispatching technique!
Does Objective C on the NeXT do something the two Think products don't?

  Theus ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 5 Jun 92 18:35:08 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (P. Hawthorne) writes:

>  Matt Mora, [e-mail], quite rightly mentions:
>. Speed of the application is dependent upon the "smartness" of the
>. compiler and the skill of the programmer not the language used.  You
>. can't make general claims like that about languages.

>  Granted. However, there must be some plausible explanation for why so
>many C programmers so often claim that C is inherently faster than Pascal,
>or why so many C programmers cite the bad points of ancient Pascal dialects
>as proof of the superiority of C.

Is this the same C that now has strict prototype checking, check pointer
types and all the nasty type checking that Pascal has? Hmmm sounds
like the same "bad points of ancient Pascal dialects as proof of the
superiority of C" is now being infiltrated into C. :-)







Matt

- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (John Wallace)
Organization: TRW Data Systems Center, Redondo Beach, CA
Date: Sat, 6 Jun 92 01:58:15 GMT

In article <[e-mail]> [e-mail] (Matt Mora) writes:
>In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
>
>>  Matt Mora, [e-mail], quite rightly mentions:
>>. Speed of the application is dependent upon the "smartness" of the
>>. compiler and the skill of the programmer not the language used.  You
>>. can't make general claims like that about languages.
>
>>  Granted. However, there must be some plausible explanation for why so
>>many C programmers so often claim that C is inherently faster than Pascal,
>>or why so many C programmers cite the bad points of ancient Pascal dialects
>>as proof of the superiority of C.
>
>Is this the same C that now has strict prototype checking, check pointer
>types and all the nasty type checking that Pascal has? Hmmm sounds
>like the same "bad points of ancient Pascal dialects as proof of the
>superiority of C" is now being infiltrated into C. :-)
>

Choice of language usually boils down to a matter of preference and
which is best supported on a system.  When I program Suns, I use C.
When I program NeXTs I use Objective C.  When I program Macs, I use
Pascal.  In each case I use the language that makes the fewest waves
on that platform.

As to "which is faster: C or Pascal", I'll agree with Matt: it depends
on the compiler.  There is nothing inherintly faster in C. Most
compiler writers acknowledge that it is much easier to make a low-end C
compiler than a Pascal compiler.  BUT, as soon as you're talking about
an optimizing compiler, it is MUCH easier to produce a highly optimizing
Pascal compiler because of the idealized for loop, strong type checking,
and rarity of pointers.  Looking at the state of things today on the Mac,
the performance of Pascal and C is within a couple of percent either
way, depending on the application.  If you want a big performance
increase (100% to 500%), use assembler.

As far as saying:
>>  ... there must be some plausible explanation for why so
>>many C programmers so often claim that C is inherently faster than Pascal,
>>or why so many C programmers cite the bad points of ancient Pascal dialects
>>as proof of the superiority of C.

It just sounds like _software racism_ to me :-)

Cheers!
John
- ----
John Wallace    [e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 6 Jun 92 00:16:24 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Matt Mora) writes:
> In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
>
> >  Matt Mora, [e-mail], quite rightly mentions:
> >. Speed of the application is dependent upon the "smartness" of the
> >. compiler and the skill of the programmer not the language used.  You
> >. can't make general claims like that about languages.
>
> >  Granted. However, there must be some plausible explanation for why so
> >many C programmers so often claim that C is inherently faster than Pascal,
> >or why so many C programmers cite the bad points of ancient Pascal dialects
> >as proof of the superiority of C.
>
> Is this the same C that now has strict prototype checking, check pointer
> types and all the nasty type checking that Pascal has? Hmmm sounds
> like the same "bad points of ancient Pascal dialects as proof of the
> superiority of C" is now being infiltrated into C. :-)

I've always though it humorous that C continues to load up with features
from the languages that hard core C people used to hate.  Your comments
about strict type checking above are one example.  C++ goes even further
in this direction adding a number of great features from Ada (operator
overloading, exception handling, and generics for instance - C++ even
uses the bazarre word pragma just like Ada :-) ).

Not that I'm complaining.  C (& C++) has gotten almost useable over
the years - thank goodness since its harder and harder to resist using it.

P.S.  If only Ada had been invented a few years later and gotten real
OOPs included we'd have a decient language for MacApp!

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --  Makers of...        --   San Jose, California USA 95117
- --                      --   voice: [phone] fax: [phone]
- --     SMOOTHIE         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 6 Jun 92 07:07:53 GMT
Organization: Reed College, Portland, Oregon


  Prometheus Hawthorne, [e-mail], writes:
. However, there must be some plausible explanation for why....  so many C
. programmers cite the bad points of ancient Pascal dialects as proof of the
. superiority of C.

  Matt Mora, [e-mail], writes:
. Is this the same C that now has strict prototype checking, check pointer
. types and all the nasty type checking that Pascal has?

  Michael Pierce, [e-mail], writes:
. I've always though it humorous that C continues to load up with features
. from the languages that hard core C people used to hate....

  Yeah. It may seem hypocritical on hindsight, but Pascal could do with
some of that vibrancy. C does seem to be very much a living language, being
extended and redefined. My father has always given me an odd perspective on
things about computers. He was a computer nerd, just like his dad was, and
there's a certain historical context that pokes up every now and then.

  For instance, some time ago, my dad asked me if I was using Algol now. I
just din't have the heart to tell him that it was Object Pascal, since this
was just after he found out how cheap megabytes of memory are for me now.
He was still a little sore. He's still lecturing me about the time he spent
weaving magnetic core memory and saying that if I can't do something in 4K,
I should just give up now. Noble... Ancient but noble.

  Then I started to notice things from my really old Encyclopedia of
Computer Science. (It was a childhood altar for me.) I had no idea at the
time, but Pascal is pretty much Algol 68 with a bunch more data types. The
object extensions are about all that has really changed with the language
since then, it begins to seem.


  Michael Pierce, [e-mail], elaborates:
. C++ goes even further in this direction adding a number of great features
. from Ada (operator overloading, exception handling, and generics for
. instance - C++ even uses the bazarre word pragma just like Ada :-) ).
. P.S. If only Ada had been invented a few years later and gotten real
. OOPs included we'd have a decent language for MacApp!

  Ada compilers sure are priced for government contractor's budgets! It
reads nicely, and I've liked what I've seen, but the user base sure is a
lot more bloated... er, sure are a lot more affluent than I am!
  Speaking of Ada, I would like to think that Pascal could incorporate the
actor-based systems paradigm and regain a bit of the luster it has lost
over the years, but the momentum does seem to be on the side of C.
  Besides, how could anyone ever convince Borland to incorporate actor
extensions into Turbo Pascal?

  Theus
  [e-mail]

+++++++++++++++++++++++++++

From: [e-mail]
Date: Sun, 7 Jun 1992 15:34:32 GMT
Organization: Actrix Information Exchange

In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
>
>   My kingdom for a new and improved object method dispatching technique!
> Does Objective C on the NeXT do something the two Think products don't?


Have you looked at C++?

The method dispatch code possible with C++ (especially the non-multiple-
inheritance style found in CFront 1.2 and "SingleObject" descendents in
Apples version) is about as efficient as it's possible to get.

- --
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"

+++++++++++++++++++++++++++

From: [e-mail] (Michael Newbery)
Date: Sun, 7 Jun 1992 21:57:15 GMT
Organization: Computing Serv. Ctr, Victoria Uni., Wellington, New Zealand

In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
>  Then I started to notice things from my really old Encyclopedia of
>Computer Science. (It was a childhood altar for me.) I had no idea at the
>time, but Pascal is pretty much Algol 68 with a bunch more data types. The
>object extensions are about all that has really changed with the language
>since then, it begins to seem.

Pardon? I assume/hope you mean Algol 60.

Algol68 has lots of stuff lacking in Pascal, including rather more data
types, operator overloading, etc. etc.

- --
[e-mail]
There is no national science just as there is no national multiplication table;

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 Jun 92 03:01:46 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
writes:
> In article <[e-mail]> [e-mail] (P. Hawthorne)
writes:
> >   My kingdom for a new and improved object method dispatching technique!
> > Does Objective C on the NeXT do something the two Think products don't?
> Have you looked at C++?

> The method dispatch code possible with C++ (especially the non-multiple-
> inheritance style found in CFront 1.2 and "SingleObject" descendents in
> Apples version) is about as efficient as it's possible to get.

   And no dynamic runtime method dispatching, something that Objective-C has.
Sigh. I guess the runtime binding standardization efforts will produce
this feature, 1994 or so.
- --
                                              Cheers, Kent


+++++++++++++++++++++++++++

From: [e-mail] (Matthias Urlichs)
Date: 23 Jun 1992 13:20:50 +0200
Organization: University of Karlsruhe, FRG

In comp.sys.mac.programmer, article <[e-mail]>,
  [e-mail] (Chris D. Nebel) writes:
< In article <[e-mail]> [e-mail] (Matt Mora) writes:
< >A few months back, someone in Dr. Dobb's was interviewed and went on about
< >the myth that C is faster than Pascal.
<
<This reminds me of an article I saw a couple of years back: it was a commentary
<by Dave Small about the trials and travails he had writing writing the Spectre,
<a (sort of) Mac emulator for the Atari ST.  He went on for a while about how
<the entire Mac system bit the big one because it was all based around that
<horrible, godawful language Pascal, instead of a nice, efficient, sensible one
<like C (which the ST OS was written in (I think.)) [this is irony, folks! No
<flames!]  His main two gripes were that (1) Pascal was hideously slow and (2)
<that any program written in Pascal was automatically really huge, because using
<just one routine from a library would put the entire library in your program
<(giving such fun things as a 200K "hello world" program).
<
< The funny thing is that both of these gripes are absolutely true -- of UCSD
< Pascal for the Apple II, the official Apple-distributed Pascal for the Apple
< II at the time.  Nothing like first impressions, eh?

The observation about linking is also true for at least one of the early
Pascal compilers for the Mac, and probably also for at least one Pascal on
the Atari. ;-) Incidentally, it's also true for about every development
system on about every existing UNIX machine. Yes, this includes C.

BTW, he's got one point -- Pascal calling conventions are a bit slower than C
conventions on the 68000. The trap dispatcher is a beast which probably would
be implemented quite differently today, also...

- --
"I've been called an evil genius by cities of assholes...  but I know who
 these people are!  And they're on my list!"
 -- Robert Crumb
- --
Matthias Urlichs  --  [e-mail] -- [e-mail]   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  [phone]     \o)/

+++++++++++++++++++++++++++

From: [e-mail]
Date: 24 Jun 92 09:32:51 GMT
Organization: Actrix Information Exchange

In article <[e-mail]> [e-mail] (Matthias Urlichs) writes:
> BTW, he's got one point -- Pascal calling conventions are a bit slower than C
> conventions on the 68000. The trap dispatcher is a beast which probably would
> be implemented quite differently today, also...

Interesting.

Over on the MSDog side, Walter Bright (author of the Zortech C and C++
(and before that Datalight) compilers) says that one of the big wins
in compiling C code using a C++ compiler is that C++ is able to use
"Pascal" calling conventions for speed.

This is because C compilers have to be prepared to accept any number
of parameters, wheras C++ (unless you use ...) and Pascal functions
have a fixed numnber of parameters.
- --
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik (High Priest of SSSM))
Date: 29 Jun 92 02:07:16 GMT
Organization: Secret Society of Software Mungers

In article <[e-mail]>, [e-mail] (Matthias
Urlichs) writes:
> BTW, he's got one point -- Pascal calling conventions are a bit slower than C
> conventions on the 68000. The trap dispatcher is a beast which probably would
> be implemented quite differently today, also...

So, does anyone know the story why Windows uses pascal calling conventions in
their
API, performance reasons?

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Organization: Symantec Corp.
Date: Mon, 29 Jun 1992 14:10:33 GMT

In article <[e-mail]> [e-mail] (Kent Sandvik (High Priest of SSSM)) writes:
   In article <[e-mail]>, [e-mail] (Matthias Urlichs) writes:
   > BTW, he's got one point -- Pascal calling conventions are a bit
   > slower than C conventions on the 68000. The trap dispatcher is a
   > beast which probably would be implemented quite differently
   > today, also...

   So, does anyone know the story why Windows uses pascal calling
   conventions in their API, performance reasons?

Code size. Since the bulk of glue code is pushing args on the stack
and popping them off, and since Pascal conventions require that the
callee pops off the arguments, using Pascal calling conventions places
half of that code inside the Mac ROMs (or Windows DLLs). If your code
contains more than one call to any single library routine, then you've
saved a couple bytes of code.

Many DOS compilers provide an option that changes all of your C
routines to use Pascal calling conventions for just this reason
(except for those explicitly declared as cdecl, so you can still call
stdio routines). You can of course do this explicitly by using the
pascal keyword before each function, or by using extern "Pascal" in
C++.

Some C compilers have an optimization that reduces the code size
difference by waiting until the end of a block/function to remove the
arguments from the stack; in THINK C this is called "defer and combine
stack adjusts".

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: 30 Jun 92 23:29:46 GMT
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Kent Sandvik (High Priest of SSSM)) writes:
>In article <[e-mail]>, [e-mail] (Matthias
>Urlichs) writes:
>> BTW, he's got one point -- Pascal calling conventions are a bit slower than C
>> conventions on the 68000. The trap dispatcher is a beast which probably would
>> be implemented quite differently today, also...
>
>So, does anyone know the story why Windows uses pascal calling conventions in
>their
>API, performance reasons?

You mean is wasn't just because that is what Apple used?????

Grin.

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Annon:    [e-mail]
"Reporter : Mr Gandhi, what do you think of Western Civilization ?
Gandhi : I think it would be a good idea."

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Urlichs)
Date: 4 Jul 92 04:51:23 GMT
Organization: University of Karlsruhe, FRG

In comp.sys.mac.programmer, article <[e-mail]>,
  [e-mail] writes:
< In article <[e-mail]> [e-mail] (Matthias Urlichs) writes:
< > BTW, he's got one point -- Pascal calling conventions are a bit slower than C
< > conventions on the 68000. The trap dispatcher is a beast which probably would
< > be implemented quite differently today, also...
<
< Interesting.
<
< Over on the MSDog side, Walter Bright (author of the Zortech C and C++
< (and before that Datalight) compilers) says that one of the big wins
< in compiling C code using a C++ compiler is that C++ is able to use
< "Pascal" calling conventions for speed.
<
< This is because C compilers have to be prepared to accept any number
< of parameters, wheras C++ (unless you use ...) and Pascal functions
< have a fixed numnber of parameters.

I don't know zilch about 80x86 calling conventions.  ;-)

On the Mac, however, C and Pascal conventions pass arguments on the stack
(except for the return value in C). Specifically:

        C                Pascal

                    (Reserve space for return value
                            on stack)
    Push args, right to left    Push args, left to right
    Call function            Call function
        [ Function ]            [ Function ]
        (Move return value into D0)        (Move return value onto stack)
                        Pop return address into register
                        Pop arguments off stack
        Return via RTS            Return via register
    Pop arguments off stack        (Get result off stack)

Stuff in parentheses only applies to functions.

Obviously, C is cheaper. The C conventions have the added benefit that
you can let the arguments accumulate on the stack and then pop them all
at once.
Having a variable number of arguments is not interesting in the C case
because the first arg always is at the top of the stack; thus the compiler
doesn't have to do anything special for varargs, nor does "procedure" code
differ from "function" code.

Interestingly, no Mac language uses register-based calling conventions.
Register-based calling is, in itself, obviously faster than either of the
above schemes because you don't need to access the stack. However, if you
push multiple arguments you effectively steal registers from the compiler so
that setting up the procedure call may get more expensive. Plus, the
procedure then may have to move yet-unused parameters off to the stack
in order to do its job. Whether this tends to increase or decrease running
time is anybody's guess.

- --
"A raccoon tangled with a 23,000 volt line today.  The results blacked
out 1400 homes and, of course, one raccoon."
        -- Steel City News
- --
Matthias Urlichs  --  [e-mail] -- [e-mail]   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  [phone]     \o)/

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 6 Jul 92 03:37:42 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Matthias Urlichs) writes:
> In comp.sys.mac.programmer, article <[e-mail]>,
>   [e-mail] writes:
> < In article <[e-mail]> [e-mail] (Matthias Urlichs) writes:
> < > BTW, he's got one point -- Pascal calling conventions are a bit slower than C
> < > conventions on the 68000. The trap dispatcher is a beast which probably would
> < > be implemented quite differently today, also...
> <
> < Interesting.
> <
> < Over on the MSDog side, Walter Bright (author of the Zortech C and C++
> < (and before that Datalight) compilers) says that one of the big wins
> < in compiling C code using a C++ compiler is that C++ is able to use
> < "Pascal" calling conventions for speed.
> <
> < This is because C compilers have to be prepared to accept any number
> < of parameters, wheras C++ (unless you use ...) and Pascal functions
> < have a fixed numnber of parameters.
>
> I don't know zilch about 80x86 calling conventions.  ;-)
>
> On the Mac, however, C and Pascal conventions pass arguments on the stack
> (except for the return value in C). Specifically:
>
>         C                Pascal
>
>                     (Reserve space for return value
>                             on stack)
>     Push args, right to left    Push args, left to right
>     Call function            Call function
>         [ Function ]            [ Function ]
>         (Move return value into D0)        (Move return value onto stack)
>                         Pop return address into register
>                         Pop arguments off stack
>         Return via RTS            Return via register
>     Pop arguments off stack        (Get result off stack)
>
> Stuff in parentheses only applies to functions.
>
> Obviously, C is cheaper.

Yeah, until you get into things like function results bigger than will
fit into a register. Also, the Pascal convention is quicker for short
routines, particularly those written in assembler. This is because you
can pop each argument off the stack as you use it, eg:

ULMUL    proc    export
;+
; Function ULMul
;   (
;     A, B : LongInt
;   ) : LongInt
; returns unsigned long-integer product of A and B.
;-
    move.l    (sp)+, a0    ; return address
    move.l    (sp)+, d1    ; value of B
    move.l    (sp)+, d0    ; value of A
... main part of routine omitted ...
    move.l    d2, (sp)    ; return result
    jmp    (a0)        ; all done
    endproc ; ULMUL


> Interestingly, no Mac language uses register-based calling conventions.

I think Consulair Mac C used to. And the current version of MPW C of course
supports it. I guess this convention works best for leaf routines--those which
don't in their turn call other routines. Otherwise you still have to stack
those values when making the inner routine call, which gives you your stack
overhead back again.

A similar thing applies to the decision as to whether the called routine
or the caller has to save registers used internally by the called routine.
The Metrowerks Modula-2 compiler by default makes the caller responsible for
the saving, which is contrary to the usual Mac system convention. Again, I'd
say this works best for leaf routines, and doesn't gain you anything in other
situations (except headaches when I forget to call SAVEREGS in a routine being
called by some system code :-)).

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
To someone with a hammer and a screwdriver, every problem looks
like a nail with threads.

+++++++++++++++++++++++++++

From: Quinn <[e-mail]>
Organization: The University of Western Australia
Date: Tue, 7 Jul 1992 02:08:12 GMT



In article <[e-mail]> Matthias Urlichs,
[e-mail] writes:
>On the Mac, however, C and Pascal conventions pass arguments on the stack
>(except for the return value in C). Specifically:
>
>        C                Pascal
>
>                    (Reserve space for return value
>                            on stack)
>    Push args, right to left    Push args, left to right
>    Call function            Call function
>        [ Function ]            [ Function ]
>        (Move return value into D0)        (Move return value onto stack)
>                        Pop return address into register
>                        Pop arguments off stack
>        Return via RTS            Return via register
>    Pop arguments off stack        (Get result off stack)
>
>Obviously, C is cheaper.
 ^^^^^^^^^^^^^^^^^^^^^^^
Hmmm, "cheaper" may be obvious to you.  And I'd certainly agree with
"faster"
and more "flexible" but "smaller" I'm not so sure.  C has every function
*caller* removing arguments, Pascal has every *function/procedure*
removing
arguments. Now a function must be called at least as many times as it's
declared (Yay for smart linking!) thus is seems that Pascal could be
making
smaller code.

Not that this is significant in the global scale of things.  Like the hit
Pascal takes because the 68000 doesn't have an RTD instruction.  I'm just
here to suggest that "all sweeping generalisations are wrong".

However C returning function results in D0 is a Big Win (tm).  But life
is easy when you only have to worry about returning longs and smaller
from functions.  Perhaps it would have been smarter for Pascal to
use a register for small things and the stack for large.

Regardless it would seem IMHO that register based calling conventions are
the way to go anyway.  [That's most probably because I like putting lots
of small subroutines in my program rather than few big one.  Hell, I think
it makes them easier to read (-: ]  But all these things were graven in
stone
a very long time ago.

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Quinn says "Don't put tabs in your postings to Mac groups!"

---------------------------

End of C.S.M.P. Digest
**********************